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1 Introduction 

We recently had occasion to study and admire the join algorithm of Ngo, Porat, Re and Rudra 
pi (henceforth NPRR). Given bounds on the input relation sizes, the running time of NPRR 
is bounded by the largest possible result size, which may be determined using the fractional 
edge cover method 111. 

Our commercial Datalog system LogicBlox®employs a novel join algorithm {leapfrog triejoin) 
which performs conspicuously well over diverse benchmarks; we were curious how it would 
compare. We establish that leapfrog triejoin is also worst-case optimal for fully conjunctive 
queries, and in fact satisfies a more exacting optimality criterion. Our algorithm may offer 
a practical competitor to NPRR, being easy to absorb, simple to implement, and having a 
concise optimality proof. 
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1.1 Notations and conventions 

All logarithms are base 2, and [n] = {1, . . . , n}. Complexity analyses assume the RAM ma- 
chine model. 

We assume structures defined over universes which are subsets of N, the natural numbers. 
In algorithm descriptions we use int as a s}monym for N. 

ForabinaryrelationR(fl,&),wewriteR(fl,_) fortheprojection 7rfl(R),i.e.,theset {fl : 3b. {a, b) G 
R}. For a parameter a, we write Ra (b) for the curried version of R, i.e., the relation {b : {a, b) G 
R). Similarly for relations of arity > 2, e.g., for S{a, b, c) we write Sa{b, c) and Sa,b{c) for cur- 
rying. 



2 Leapfrog Triejoin 

Leapfrog triejoin is a a join algorithm for 3i queries, that is, queries definable by first-order 
formulae without universal quantifiers (and, needless to say, excluding negated existential 
quantifiers.) We first describe the leapfrog join for unary relations (Section |2.1| . This ex- 
tends without fuss to the triejoin algorithm for fully conjunctive queries (Section |2.4| . With 
minor embellishments, leapfrog triejoin can tackle 3i queries; we mention these extensions 
in passing, but the focus (and particularly, the complexity analysis) is for fully conjunctive 
queries. 



2.1 Leapfrog join for unary predicates 

Leapfrog join is a variant of sort-merge join which simultaneously joins unary relations 
Ai{x), . . . , A^[x) and has running time proportional to the size of the smallest relation. It 
is of no particular novelty, but serves as the basic building block for Leapfrog Triejoin. Its 
performance bound underpins the complexity analyses which follow. 

For the purposes of leapfrog join, the relations A, C N are presented in sorted order by linear 
iterators, one for each relation, with this interface: 

int key() Returns the key at the current iterator position 

next() Proceeds to the next key 

seek(int seekKey) Position the iterator at a least upper bound for seekKey, 

i.e. the least key > seekKey, or move to end if no such key exists. 
The sought key must be > the key at the current position. 

bool atEnd() Returns true if iterator is at the end. 

All iterator methods for a relation A are required to take O(logN) time, where N = |A| is 
the cardinality. Moreover, if m keys are visited in ascending order, the amortized complexity 
is required to be 0(1 + log(N/ m)), as usual for balanced tree data structures]^ 

^ For example, if every key is visited in order then m = N and the amortized complexity is 0(1). Rather than 
returning to the tree root for each seek() request, the iterator ascends just far enough to find an upper bound for 
the key sought. 
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Leapfrog join is itself implemented as an instance of the linear iterator interface; it provides 
an iterator for the intersection Ai n • • • n Aj^. The algorithm uses an array lter[0 . . .k — 1] 
of pointers to iterators, one for each relation. In operation, the join tracks the smallest and 
largest keys at which iterators are positioned, and repeatedly moves an iterator at the small- 
est key to a least upper bound for the largest key, 'leapfrogging' the iterators until they are 
all positioned at the same key. Detailed descriptions of the algorithm follow; some readers 
may choose to skip to the complexity analysis (Section [Z2] |. 

When the leapfrog join iterator is constructed, the following method is used to initialize and 
find the first result: 

Function leapfrog-init 

if any iterator has atEnd() true then 

atEnd := true ; 
else 

atEnd := false ; 

sort the array lter[O..A: — 1] by keys at which the iterators are positioned ; 
p:=0; 

leapfrog-searchO 



The main workhorse is the leapfrog-search algorithm, which finds the next key in the inter- 
section Ai n ■ ■ ■ n A],: 

Function leapfrog-search 

x' := lter[(p - 1) mod /c].key() ; 
while true do 

X := lter[p].key() ; 
if X = x' then 
key := x ; 
return; 
else 

lter[p].seek(x'); 
if lter[p].atEnd() then 
atEnd := true ; 
return; 
else 

x' := lter[p].key(); 
p := p+1 mod k; 



// Max key of any iter 
// Least key of any iter 
// All iters at same key 



Immediately after leapfrog-init(), the leapfrog join iterator is positioned at the first result, if 
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Fig. 1: Example of a leapfrog join of three relations A, B, C, with A = {0, 1, 3, 4, 5, 6, 7, 8, 9, 1 1 } and B, 
C as shown in the second and third rows. Initially the iterators for A,B,C are positioned (respectively) 
at 0, 0, and 2. The iterator for A performs a seek(2) which lands it at 3; the iterator for B then performs 
a seek(3) which lands at 6; the iterator for C does seek(6) which lands at 8, etc. 



any; subsequent results are had by calling leapfrog-next(). 

Function leapfrog-next 

lter[p].next(); 
if lter[p].atEncl() then 
I atEnd := true; 
else 

p := p+1 mod k; 
leapfrog-search(); 



Figure [T] illustrates a join of three relations. 

To complete the linear iterator interface, we define a leapfrog-seek() function which finds the 
first element of Ri H • • • H i^/^ which is > seekKey: 



Function leapfrog-seek(int seekKey) 

\ter[p].seek{seekKey); 
if lter[p]. atEnd then 
I atEnd := true; 
else 

p := p+1 mod k; 
leapfrog-search(); 



The leapfrog join is able to do substantially better than pairwise joins in some scenarios. For 
instance, suppose we have relations A, B, C where A = {0, • ■ ■ ,2n — l},B = {n, ■ ■ ■ , 3n — 1 }, 
and C = {0, ■ ■ ■ , n — 1, 2n, . . . , 3n — 1}. Any pairwise join will produce n results, but the 
intersection A n B fl C is empty; the leapfrog join determines this in 0(1) steps|^ 

^ Note, however, that this bound does not hold if we apply a random permutation to the imiverse. 
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Relation A{x,y,z) 

(1,3,4) 
(1,3,5) 
(1,4,6) 
(1,4,8) 
(1.4,9) 
(1,5,2) 
(3,5,2) 

Fig. 2: Example: Trie presentation of a relation A(x,y,z). When open() is invoked at some 
node n, the linear iterator methods next(), seek() and atEnd() present the children of n. In the 
above example, invoking open() thrice on an iterator positioned at r would move to the leaf 
node [1, 3, 4]; next() would then move to leaf node [1, 3, 5]; another next() would result in the 
iterator being atEnd(). The sequence up(), next(), open() would then move the iterator to leaf 
node [1,4,6]. 

2.2 Complexity of leapfrog join 

In the complexity analyses which follow, we omit constant factors which depend only on the 
join structure; e.g. for a join of k unary relations, factors depending only on k are omitted. 

Let Nmin = iriin{|Ai|,. . ., be the cardinality of the smallest relation in the join, and 
Nmax = max{ I Ai I , . . . , I A;c I } the largest. 

Proposition 2.1. The running time of leapfrog join is O {Nmin log {Nmax /Nmin))- 

Proof. The leapfrog algorithm advances the iterators in a fixed order: each iterator is ad- 
vanced every k steps of the algorithm. An iterator for a relation with cardinality N can be 
advanced at most N times before reaching the end; therefore the number of steps is at most 
k • Nmin- An iterator which visits m of N values in order is stipulated to have amortized cost 
0(1 + log(N/ m)); the iterator for a largest relation will have N = Nmax and m = Nmin, for 

total cost Nmin " 0(1 + log{Nmax/Nmin))- □ 




2.3 Trie iterators 



We extend the linear iterator interface to handle relations of arity > 1. Relations such as 
A{x,y,z) are presented as tries with each tuple {x,y,z) G A corresponding to a unique path 
through the trie from the root to a leaf (Figure |2]). 

Upon initialization, trie iterators are positioned at the root r. The linear iterator API is aug- 
mented with two methods for trie-navigation: 

void open(); Proceed to the first key at the next depth 
void upO; Return to the parent key at the previous depth 
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A trie iterator for a materialized relation is required to have 0(log N) time for the open() and 
upO methods. 

With a bit of bookkeeping and no particular cleverness, a linear iterator for a sequence of 
tuples {x, y, z) can be presented as a Trielterator and vice versa, with each operation taking 
O(logN) time0 



2.4 Leapfrog Triejoin 

We describe here the Leapfrog Triejoin algorithm for conjunctive joins. 

The triejoin algorithm requires the optimizer to choose a variable ordering, i.e., some permu- 
tation of the variables appearing in the join. For example, in the join R{a, b), S {b, c), T{a, c) 
we might choose the variable ordering [a, b, c] . Choosing a good variable ordering can be 
crucial for performance; 

Triejoin requires a restricted form of conjunctive joins, attained via some simple rewrites: 

1. Each variable can appear at most once in each argument list. For example, R{x,x) 
would be rewritten to R(x, y), x = y to satisfy this requirement]^ 

2. Each argument list must be a subsequence of the variable-ordering. For example, if the 
chosen variable ordering were [a, b, c] and the join contained a term U{c,a), we would 
rewrite this to U'{a,c) and define an index U'{a,c) = U{c,a). (In practice we install 
indices automatically when required by such rewrites, and maintain them for use in 
future queries.) 

3. Each relation symbol appears at most once in the query. For a query such as E{x,y), 
E{y,z) we simply introduce a copy E' = E and rewrite to E{x,y), E'{y,z). This avoids 
awkwardness in the complexity analysis, and is not required for implementation pur- 
poses. 

4. Constants may not appear in argument lists. A subformula such as A[x, 2) is rewritten 

to A(x,y),C2(y),whereC2 = {2}^ 

Leapfrog triejoin employs one leapfrog join for each variable. Consider the example R(fl, b), 
S{b,c), T{a,c) with the variable ordering [a,b,c]. The leapfrog joins employed for the vari- 
ables a, b, c areQ 

Variable Leapfrog join Remarks 

a R {a, _), r(fl, _) Finds a present in R, T projections 

b Ra{b),S {b, _) For specific a, finds b values 

c Sj, (c), Tfl (c) For specific a, b, finds c values 



^ For example, to perform a next() operation when positioned at the node x = 1 of Figure seek the least 
upper bound of (1, +oo, +oo) in the linear presentation of tuples; this will reach the record (3, 5, 2). 
^ The X = y term may be presented as a nonmaterialized view of a predicate Id{x, y) (x = y) . 
^ In practice C2 can be presented as a nonmaterialized view. 

^ Recall that R{a,_) is the projection {a : 3b . {a,b) 6 R}, and Ra{b) is the 'curried' form {b : {a,b) 6 R}. 
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Fig. 3: Example for R{a,b), S{b,c), T{a,c) with variable ordering [a,b,c] of the relationship 
between the iterator arrays of the leapfrog joins for each variable, and the trie iterators for R, 
S, and T. 



The topmost leapfrog join iterates values for a which are in both the projections R{a,_) and 
T{a,_). When this leapfrog join emits a binding for a, we can proceed to the next level join 
and seek bindings for b from Ra{b),S{b,_). For each such b, we can proceed to the next level 
and seek a binding for c in S},{c),Ta{c). When a leapfrog join exhausts its bindings, we can re- 
treat to the previous level and seek another binding for the previous variable. Conceptually, 
we can regard triejoin as a backtracking search through a 'binding trie.' 

At initialization, the triejoin is provided with a trie iterator for each relation in the join. Since 
relations are presented by trie iterators, nonmaterialized views may be used in place of re- 
lations. (Example: we could construct a triejoin for A{x),D{x,y) where D{x,y) presents a 
nonmaterialized view of B{x,y) V C{x,y).) 

It profits us to define triejoin as an implementation of the trie iterator interface. That is, 
triejoin presents a nonmaterialized view of the join result, so result tuples can be retrieved 
by exploring the trie using the open(), next(), etc. methods. We can then define a variant 
of triejoin for disjunctive joins, which also implements the trie iterator interface; this lets 
us build trie iterators for queries containing arbitrary nestings of disjunction and conjunc- 
tion. Adding trie iterators for complements and projections completes the toolbox needed to 
tackle 3i queries. 



2.5 Triejoin implementation 

The triejoin initialization constructs an array of leapfrog join instances, one for each variable. 
The leapfrog join for a variable x is given an array of pointers to trie-iterators, one for each 
atom in whose argument list the variable appears. The leapfrog joins use the linear-iterator 
portion of the trie iterator interfaces; the up-down trie navigation methods are used only 
by the triejoin algorithm. The triejoin uses a variable depth to track the current variable for 
which a binding is being sought; initially depth = —1 to indicate the triejoin is positioned 
at the root of the binding trie (i.e., before the first variable.) Depths 0, 1, . . . refer to the first, 
second, etc. variables of the variable-ordering. 

The linear iterator portions of the trie-iterator interface (namely key(), atEnd(), next(), and 
seek()) are delegated to the leapfrog join for the current variable. (At depth -1, i.e., the root, 
only the operation open() is permitted, which moves to the first variable.) It remains to 
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define the open() and up() methods, which are trivial: 

Function triejoin-open 

depth := depth + 1 ; // Advance to next variable 

for each iter in leapfrog join at current depth do 

iter.open() ; 
end 

call leapfrog-init() for leapfrog join at current depth 



Function triejoin-up 

for each iter in leapfrog join at current depth do 

iter.upO ; 
end 

depth := depth - 1 ; 



// Backtrack to previous variable 



This completes the trie iterator interface. To enumerate the satisfying assignments of the join, 
we employ an adaptor which turns a trie-iterator into a linear iterator of tuples, a simple 
exercise we omit here. 

3 Complexity of Leapfrog Triejoin 

We consider here the complexity of triejoin for fully conjimctive joins of materialized rela- 
tions. 

3.1 The proof strategy 

To introduce the proof strategy, consider the example join: 

Q(a, b, c) = R{a, b),S{b, c), T{a, c) 

with variable-ordering [a,b,c]. Suppose that \R\ < n, \S\ < n, and |T| < n. The fractional 
cover boimd yields \ Q\ < rv'^'^, a worst case realized by setting R = S = T = [n^^-^] x [n^^-^j. 

We wish to show that the triejoin runs in 0{n^^^ logn) time for this example. Recall that a 
leapfrog join of two unary relations U, V requires at most inf { | LT | , | V | } iterator operations. It 
is readily seen that the cost at the first two trie levels [a, b] cannot exceed \R\ linear iterator 
operations: at the first trie level the leapfrog join is limited by |R(fl,_)| < \R\, and at the 
second trie level the nimiber of iterator operations is controlled by: 

i: mm4b)i\s{h_)\}< i: \Ra{b)\ 

«€R„(_),T(a,_) fl€R„(_),T(fl,_) 

Therefore the number of linear iterator operations at the first two trie levels is 0(n). At the 
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third trie level, the number of linear iterator operations is controlled by: 

inf{|Sfc(c)UT„(c)|} (1) 

{a,b)GR{a,b),S{b,_),T{a,_) 

We now wish to prove that the quantity is < n^^-^. We do this by renumbering the c values 
of the relations such that the join produces a number of results equal to ([TJ. 

For example, suppose we had these trie presentations of R, S, T: 

R{a,b) S{b,c) T{a,c) 

a 7 
b 4 

c 1 4 ^5 ^9 2 3 5 




This would produce only the result tuple (7,4,5). To get a result size equal to (njl we can 
renumber the c values to produce one result for every leaf of T (the smaller relation): 

R{a,b) S{b,c) T{a,c) 
a 7 
b 4 

c 1 ^2 ^3 12 




This results in exactly three results (7,4,0), (7,4, 1), and (7,4,2), equalling ([TJ. 

In general, the renumbering produces modified relations S', T which each have cardinality 
< n. Since n^^"^ is an upper bound on the result size, it follows that ([T]) is at most n^^^. 

The renumbering is accomplished as follows: 

• Construct S' {b, c) by renumbering the c values of each Sf, -subtree to be 0, 1, . . ., i.e.: 

S'{b,_) = S {b, _) Keep b values the same 

S'b = {0/ 1/ • • • / |Sb| — 1} For each b, renumber the c values 

• Similarly, renumber the c values of each Ta subtree: 

T'{a,_) = T{a,_) Keep a values the same 

= {0, 1, . . . , I Tfl I — 1 } Renumber the c values 
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When we compute the leapfrog join of S[, = {0, 1, . . . , | S;, | — 1 } with = {0, 1, . . . , | T,, | — 1 }, 
we get exactly inf { | Sj, | , | T,, | } results. This holds for every join at the third trie level; therefore 
the query result size is exactly the quantity ([T]). Since the fractional cover bound gives an 
upper bound of rr'^'^ on the query result size, we have: 

^ inf{|S,(c)UT«(c)|}<n3/2 

{a,b)<^R(a,h),S(b,_),T(a,_) 

Hence the running time of leapfrog triejoin for the example is 0{rr'^^ log n)F] 



3.2 The renumbering transform 

We generalize the renumbering transformation introduced in the previous section. For a re- 
lation R(x,i/,z), a renumbering at variable v is obtained by traversing the trie representation 
of R, and: 

• If the variable v appears in the argument list at depth d, then renumber the children of 
nodes at depth d — 1 to be 0, 1, . . .; otherwise, do nothing. 

• Replace all values for variables appearing after v in the key-ordering with 0. 

• Eliminating any duplicate tuples. 

The resulting relation R' is called a renumbering of R. Figure [l] illustrates renumberings of a 
relation R{x, y, z) at various depths. 



3.3 Triejoin costs 

Let R^, . . . , R"' be the relations in the join, and V = [vi, . . . ,V](]he the chosen variable order- 
ing. Each atom (relation) in the join takes as arguments some subset of the variables V, in 
order. For a relation R{vi, vr, V3, 1^4), we use this notation for currying: 

We write R^i{vi, . . .) for the curried version of all variables strictly before Vi in the ordering; 

e.g. R<i{vi) = Ry^^y^^y^{vi). 

Write Qi{vi,V2, ■ ■ ■ ,Vi) for the join 'up to' variable i; this is obtained by replacing variables 
. . .,Vk with the projection symbol _ in the query, and omitting any atoms which con- 
tain only projection symbolsj^ For example, with Q = R{a, b),S{b, c), T{a, c), and key order 

It turns out for the specific worst case wtiere R = S = T = [n-^^^j x [«^/^] the running time is 0{n^^^), i.e., 
we can drop the log factor because of the amortized complexity of the iterators. It is plausible that the log factor 
could be dropped for arbitrary R, S, T. However, there are some queries (i.e. not the R-S-T example) where the 
log factor appears unavoidable. 

^ Note that Q,- is generally a strict superset of the projection of the query result Q{vi,V2, ■■■ ,Vi, _). 
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4 5 6 8 9 2 2 
(a) A relation R{x,}/,z) 

r 






(c) Renumbered at depth 1 




10 1 2 
(b) Renumbered at depth 2 














(d) Renumbered at depth 



Fig. 4: Example of the renumbering transform applied to a relation R{x,y,z). 
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[a, b, c], we would have: 

Qi = R{a,_),T{a,_) 

Qi = R{a,h),S{h,_),T{a,_) 

Q^ = R{a,h),S{h,c),T{a,c) 

Let Rj,^ {vi), . . . , RI^. {vi) be the relations in the leapfrog join at level /. Let C, be the sum-inf 
of the leapfrog triejoin at tree depth i: 

C, = mf{\Rljv„_ _)| \Rijvi, _...,_)]} 

{vi,...,Vi-i)GQi-i 

To compute the join result, one uses the trie iterator presented by leapfrog triejoin to com- 
pletely traverse the trie. The time cost of this is immediate from the leapfrog complexity 
bound, and the 0(log N) performance requirement for open() and up(): 

Proposition 3.1. The running time of Leapfrog Triejoin is 0((X^,£[|f] Q) log Nmax)- 



3.4 Families of problem instances 

We write Str[(7] for finite structures with signature (vocabulary) a. A family of problem in- 
stances is a family (K„)„£isj indexed by a parameter n G N, where each K„ C Str[(7] is a class 
of finite relational structures, and (z < =^ (K, C Ky). (Example: graphs with at most n 
edges is a family of problem instances.) 

More generally, we can choose a tuple of parameters n G N*^, with the usual partial ordering 
on tuples, so that ni < n[, . . . ,n]^ < n'^. implies K[„j C K[„/ (Example: let a contain 
the binary relation symbols R,S,T, and define Kr,s,f to be structures with \R\ < r, \S\ < s, 
and \ T\ < t.) 

The signature a is stipulated to include a query relation symbol Q. The query is defined by 
some formula ^{x), with every structure A G K„ satisfying A \= {Q{x) o tp{x)). (For now, 
we restrict the query relation to be definable by a fully conjunctive join.) For simplicity, we 
take X to be the variable ordering for the triejoin. 

Given structures A, A', we say A' is a renumbering of A if it is obtained by choosing some 



relation of A and renumbering it at some depth, as per Section 3.2 



A family of problem instances is closed under renumbering when for every A G K„, if A' is a 
renumbering of A, then A' G K„ also. 

Theorem 3.2. Let 

1. {K„)„(zf>} be a family of problem instances closed under renumbering, 

2. q{n) = sup_^gj(^^ IQ-^I be the largest query result size for any structure in K„, and 

3. M{n) be the cardinality of the largest relation (excluding Q) in any structure ofK„. 
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Then, Leapfrog Triejoin computes Q in 0{q{n) log M(n)) time over {K„] 



Proof. (By contradiction). Suppose the running time is co{q{n) log M(n)). From Prop. 3.1 the 
running time of leapfrog triejoin is 0((Co + ■ ■ ■ + C;c_i) log M(n)), where C, is the sum-inf 
for the leapfrog join of variable Vj. For this to be co{q{n) log M(n)), some variable Vj must 
have Cj G co{q{n)) for infinitely many instances A. For each such A, renumber all relations 
for variable c,. Revise Q{v) appropriately. This results in structures A' with |Q-^ | = Q. 
Since the family is closed under renumbering. A' S K„; but |Q-^ | G co{q{n)), contradicting 
the definition of q{n). □ 

The worst-case optimality in the sense of NPRR [2] is a trivial corollary: 

Corollary 3.3. The running time of Leapfrog Triejoin is bounded by the the fractional edge cover 
bound, up to a log factor. 

Example: for the R, S, T example we could define the family of instances to be |R| < |S | < 
1 7^1 1^ n; since renumbering does not increase the sizes of the relations, the family is closed 



under renumbering. The fractional edge cover provides the bound q{n) of Theorem 3.2 
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